In one approach of programming management, the Simple Network Management Protocol (SNMP), which enables client/server relationships, allows a manager console to manage a remote network device, through a User Datagram Protocol/Internet Protocol (UDP/IP) network. Typically, the client application is referred to as the network manager, and an application program residing and running on the remote network device is referred to as the SNMP agent, which generates information about the device, organizes the information in a database referred to as the MIB (Management Information Base), maintains the MIB, answers the request of the manager, etc. The SNMP protocol also defines primitives to get and set properties of program object instances as defined in the MIB. However, both the agent and the manager must implement the full SNMP protocol, and the agent must store and retrieve management data as defined by the MIB. Even though SNMP primitives allow the manager to get and set properties of object instances defined in the MIB, it is not possible to run object methods and perform actions on the managed system. Further, the approach requires additional and specific software to equip the SNMP management with a graphic-user interface (GUI) on the manager side.
A common-gateway-interface (CGI) program allows users to control applications on a system hosting an HTTP server. Therefore, an HTTP client, via the CGI program, can interact with the application to be controlled on the server. Unfortunately, CGI-based programs are difficult to develop, require lots of overheads, and do not maintain persistent data across client requests, multiple clients, multiple applications, etc. In terms of performance, portability, extensibility, and maintainability, etc., the traditional CGI approach is also inferior to web applications run by application servers.
Some approaches allow server pages to communicate with external common-object-request-broker architecture (CORBA) or COM objects provided by an application. However, these approaches require the embedment of CORBA/COM infrastructure in the application system. Their complex nature, along with the incompatibility between different implementations, prevents their adoption for performance-critical and real-time processes or for managing embedded applications, which are typically “light-weighted,” e.g., designed to work with limited system resources such as memory, processor power, input/output interfaces, etc. For use in the network elements, CORBA is known to be too slow, too unpredictable, and too big.
Another approach includes management tools that are based on GUIs and use management protocol like CORBA-based management wherein each management request is translated into a remote invocation of a management procedure via message passing. The management request processed by the management server produces a message of the format expected by the GUI client application. However, in addition to the disadvantages of using CORBA as mentioned above, this approach is less open and often ends with proprietary message formats or remote procedures.
Based on the foregoing, it is desirable that mechanisms be provided to solve the above deficiencies and related problems.